7.04. Service Mesh

ДЛЯ НОВИЧКОВНЕ ДЛЯ НОВИЧКОВНЕ ОБЯЗАТЕЛЬНОВ РАЗРАБОТКЕ

Разработчику Архитектору Инженеру

Service Mesh

Современные распределённые приложения строятся по принципу микросервисной архитектуры. Каждый микросервис представляет собой независимую программную единицу, выполняющую узкую функцию и взаимодействующую с другими сервисами через чётко определённые интерфейсы. По мере роста количества сервисов увеличивается сложность их взаимодействия. Возникают задачи маршрутизации запросов, обеспечения отказоустойчивости, контроля доступа, сбора метрик и управления версиями. Эти задачи выходят за рамки бизнес-логики отдельного сервиса, но остаются критически важными для стабильности всей системы.

Service mesh — это выделенный уровень инфраструктуры, предназначенный для управления межсервисным взаимодействием. Он абстрагирует сетевую логику от кода приложений, обеспечивая централизованное управление трафиком, безопасность, наблюдаемость и надёжность. Service mesh не заменяет микросервисы, а дополняет их, предоставляя единый механизм для решения общих задач связи между компонентами системы.

Межсервисное взаимодействие как основа

Межсервисное взаимодействие — это процесс обмена данными между независимыми компонентами распределённой системы. В простейшем случае один сервис отправляет HTTP-запрос другому, получает ответ и продолжает выполнение. Однако в реальных условиях этот процесс включает множество дополнительных аспектов:

• Обнаружение сервисов: система должна знать, где находится нужный сервис и какие экземпляры доступны.
• Балансировка нагрузки: запросы распределяются между несколькими экземплярами одного сервиса для равномерного использования ресурсов.
• Тайм-ауты и повторные попытки: при временных сбоях система может автоматически повторить запрос.
• Цепочки вызовов: один запрос может порождать цепочку вызовов нескольких сервисов, что требует сквозной трассировки.
• Версионирование и канареечные релизы: система должна поддерживать одновременное существование нескольких версий сервиса и гибко управлять трафиком между ними.

Раньше эти функции реализовывались внутри самих сервисов — каждое приложение содержало код для работы с балансировщиком, повторными попытками, логированием и так далее. Такой подход приводил к дублированию кода, усложнению логики и снижению гибкости. Service mesh переносит всю эту логику в отдельный слой, изолируя её от бизнес-кода.

Архитектура Service Mesh: Data Plane и Control Plane

Service mesh состоит из двух ключевых компонентов: Data Plane (плоскость данных) и Control Plane (плоскость управления).

Data Plane — это совокупность прокси-компонентов, размещённых рядом с каждым экземпляром сервиса. Эти прокси перехватывают весь входящий и исходящий сетевой трафик, применяя правила, заданные системой управления. Они отвечают за маршрутизацию, шифрование, ограничение скорости, повторные попытки и другие операции в реальном времени. Прокси работают на уровне приложения и могут обрабатывать протоколы вроде HTTP, gRPC, WebSocket и других.

Control Plane — это центральный управляющий компонент, который координирует поведение всех прокси в Data Plane. Он хранит конфигурацию сети, определяет политики безопасности, управляет версиями сервисов и предоставляет интерфейсы для администрирования. Control Plane не обрабатывает пользовательский трафик напрямую, а лишь настраивает прокси и собирает диагностические данные.

Такая архитектура позволяет отделить вопросы «как передавать данные» от вопросов «что делать с данными». Разработчики сосредотачиваются на реализации бизнес-логики, а инженеры инфраструктуры — на управлении сетевыми политиками.

Сервисная сеть как инфраструктурный слой

Сервисная сеть — это реализация Service mesh в виде программного слоя, развернутого поверх существующей платформы оркестрации, чаще всего Kubernetes. Она интегрируется с кластером, автоматически внедряя прокси в каждый под (pod), содержащий микросервис. Этот процесс называется sidecar-инъекцией. Sidecar — это вспомогательный контейнер, запущенный в том же поде, что и основной сервис, и обеспечивающий все функции Data Plane.

Сервисная сеть предоставляет единый способ управления всеми аспектами взаимодействия между сервисами, независимо от языка программирования, фреймворка или версии приложения. Это особенно важно в гетерогенных средах, где одновременно используются десятки различных технологий.

Ключевые свойства сервисной сети:

• Прозрачность: приложения не обязаны знать о наличии Service mesh. Они взаимодействуют с локальным прокси так же, как раньше взаимодействовали напрямую с другими сервисами.
• Единообразие: все сервисы подчиняются одним и тем же правилам, что упрощает аудит, тестирование и эксплуатацию.
• Гибкость: политики можно изменять динамически, без перезапуска или перекомпиляции приложений.
• Наблюдаемость: сервисная сеть автоматически собирает метрики, логи и трассировки, формируя полную картину состояния системы.

---

Управление трафиком в Service Mesh

Управление трафиком — одна из центральных функций сервисной сети. Она позволяет контролировать, как запросы перемещаются между микросервисами, обеспечивая гибкость, устойчивость и предсказуемость поведения системы.

Основные механизмы управления трафиком:

• Маршрутизация: правила определяют, какой экземпляр сервиса получит запрос. Это может зависеть от версии сервиса, меток окружения (например, prod, staging), HTTP-заголовков или других атрибутов.
• Канареечные релизы: новая версия сервиса развертывается параллельно с текущей, и небольшая часть трафика направляется на неё. Если всё работает корректно, доля трафика постепенно увеличивается.
• Теневое тестирование: копия реального трафика отправляется на новую версию сервиса без влияния на основной поток. Это позволяет проверить поведение системы в боевых условиях.
• Отказоустойчивость: при недоступности целевого сервиса система может автоматически повторить запрос, перенаправить его на резервный экземпляр или вернуть заглушку.
• Ограничение скорости (rate limiting): задаётся максимальное количество запросов, которые сервис может принимать за единицу времени. Это защищает систему от перегрузки.

Все эти правила задаются декларативно — через конфигурационные файлы или API Control Plane. Они применяются ко всем прокси в Data Plane без изменения кода приложений. Это делает управление трафиком централизованным, воспроизводимым и безопасным.

Безопасность в Service Mesh

Безопасность — ещё один фундаментальный аспект работы сервисной сети. В распределённой системе каждый сервис потенциально может стать точкой входа для атаки. Service mesh обеспечивает защиту на уровне связи между сервисами.

Ключевые элементы безопасности:

• mTLS (mutual TLS): все соединения между сервисами шифруются с использованием взаимной аутентификации по сертификатам. Каждый сервис подтверждает свою личность перед отправкой данных, что исключает подмену и прослушивание трафика.
• Политики доступа: можно определить, какие сервисы имеют право вызывать другие. Например, сервис «платежи» может принимать запросы только от «корзины» и «админки», но не от «каталога».
• Централизованное управление сертификатами: Control Plane автоматически генерирует, распространяет и обновляет TLS-сертификаты для всех прокси, устраняя необходимость ручного управления ключами.
• Аудит и логирование: каждое сетевое взаимодействие фиксируется, что позволяет отслеживать подозрительную активность и проводить расследования инцидентов.

Благодаря этим механизмам, даже если злоумышленник получит доступ к одному из сервисов, он не сможет легко переместиться по сети — движение между компонентами строго контролируется.

Что такое Service Mesh: формальное определение

Service Mesh — это выделенная инфраструктурная прослойка, обеспечивающая надёжное, безопасное и наблюдаемое межсервисное взаимодействие в распределённых системах. Она реализует общие сетевые функции вне кода приложений, используя архитектуру из Data Plane (прокси) и Control Plane (управляющий центр). Service Mesh работает на уровне прикладного протокола, поддерживает динамическую конфигурацию и интегрируется с платформами оркестрации, такими как Kubernetes.

Это не библиотека, не фреймворк и не плагин. Это полноценная система, развернутая поверх приложений, которая управляет всей сетевой логикой централизованно и единообразно.

Istio: ведущая реализация Service Mesh

Istio — одна из самых популярных и зрелых реализаций Service Mesh. Она разработана совместно Google, IBM и Lyft и предназначена для работы в средах Kubernetes, хотя поддерживает и другие платформы.

Istio предоставляет полный набор функций:

• Управление трафиком с поддержкой канареечных релизов, зеркалирования и отказоустойчивости.
• Встроенную безопасность на основе mTLS и политик доступа.
• Наблюдаемость через сбор метрик, логов и распределённых трассировок.
• Интеграцию с внешними системами: Prometheus, Grafana, Jaeger, Zipkin, Kiali.

Архитектура Istio включает:

• Istiod — единый компонент Control Plane, объединяющий функции обнаружения сервисов, управления конфигурацией, генерации сертификатов и распространения правил.
• Envoy — прокси, используемый в качестве sidecar в Data Plane.
• CRD (Custom Resource Definitions) — расширения Kubernetes API, позволяющие описывать правила маршрутизации, политики безопасности и другие аспекты в виде YAML-манифестов.

Istio не требует изменения кода приложений. Достаточно внедрить sidecar-прокси и применить нужные политики через Control Plane. Это делает Istio особенно ценным в крупных организациях, где сотни сервисов написаны на разных языках и поддерживаются разными командами.

---

Envoy: прокси нового поколения

Envoy — это высокопроизводительный прокси-сервер с открытым исходным кодом, разработанный Lyft и ставший де-факто стандартом для реализации Data Plane в современных Service Mesh. Он написан на C++ и оптимизирован для работы в условиях высокой нагрузки и низкой задержки.

Envoy работает как sidecar-контейнер, размещённый в том же поде, что и микросервис. Весь сетевой трафик — входящий и исходящий — проходит через него. Это позволяет централизованно применять политики без модификации самого приложения.

Ключевые возможности Envoy:

• Поддержка множества протоколов: HTTP/1.1, HTTP/2, gRPC, WebSocket, TCP, Redis, MongoDB и другие. Envoy понимает семантику этих протоколов, что позволяет принимать решения на основе заголовков, методов, путей и других атрибутов.
• Динамическая конфигурация: Envoy получает правила маршрутизации, политики безопасности и параметры балансировки от Control Plane через API (например, xDS — Envoy Discovery Service). Это позволяет обновлять поведение прокси без перезапуска.
• Встроенная отказоустойчивость: автоматические повторные попытки, тайм-ауты, ограничение скорости, circuit breaking (размыкание цепи при частых ошибках).
• Наблюдаемость «из коробки»: Envoy генерирует подробные метрики (количество запросов, ошибок, задержек), логи доступа и поддерживает распределённую трассировку через OpenTelemetry и совместимые системы.
• Расширяемость: через WebAssembly (Wasm) или нативные модули можно добавлять собственные фильтры, преобразовывать трафик или интегрироваться со специфичными системами.

Envoy не является частью Istio — он существует как независимый проект, но именно благодаря своей гибкости и производительности стал основой для Istio, Consul Connect, AWS App Mesh и других решений. Его архитектура позволяет использовать его не только в Service Mesh, но и как edge-прокси (API gateway), балансировщик нагрузки или компонент сервисной шины.

Control Plane: мозг сервисной сети

Control Plane — это центральный управляющий компонент Service Mesh, отвечающий за координацию всей системы. Он не обрабатывает пользовательский трафик, но определяет, как этот трафик должен обрабатываться.

Основные функции Control Plane:

• Обнаружение сервисов: сканирует платформу оркестрации (например, Kubernetes API) и строит актуальный реестр всех доступных сервисов и их экземпляров.
• Распространение конфигурации: передаёт правила маршрутизации, политики безопасности и параметры наблюдаемости всем прокси в Data Plane через безопасные каналы.
• Управление жизненным циклом сертификатов: генерирует, подписывает и ротирует TLS-сертификаты для обеспечения mTLS между сервисами.
• Интерфейсы администрирования: предоставляет CLI, веб-интерфейсы и API для настройки поведения сети.
• Агрегация данных: собирает метрики и трассировки от прокси, нормализует их и передаёт в системы мониторинга.

В Istio функции Control Plane объединены в компоненте Istiod. Он заменил ранее существовавшие отдельные сервисы (Pilot, Citadel, Galley), упростив архитектуру и повысив надёжность. Istiod использует Kubernetes CRD для хранения конфигурации, что делает управление естественным для пользователей Kubernetes.

Control Plane работает в режиме «push»: при изменении конфигурации он немедленно отправляет обновления всем затронутым прокси. Это обеспечивает согласованность состояния сети и минимизирует время реакции на изменения.